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I. INTRODUCTION 



Despite being the target of considerable attention for the last ten years, there is still little consensus 
regarding exactly what factors are the critical elements in designing an effective help system. To be effective, 
a help system must be flexible enough to serve the needs of all users, from the beginning user to the highly 
experienced. The following sections discuss the basic help system structures and what information is used by 
the system to generate the assistance response. 

A, CHARACTERISTICS OF HELP SYSTEMS 

Borenstein [BOREN 85] defines an online or interactive help system to be “computer software that has 
as its primary function the task of providing the user with information that will assist in the use of some other 
software system.” The typical help system is designed to execute quickly and provides a set answer in 
response to an explicit user request. The objective is to improve the user’s knowledge and proficiency with 
the application. Variations in the user-help system process include the help mechanism; that is, how the help 
system is accessed, the question being submitted, the user asking the question and the situation from which 
the question emerges. 

Houghton states in [HOUGH 90] that most help systems are initiated by the user explicitly entering a 
command-based request - for example “help ccommand name>”. The ccommand name> is then used by the 
help system as an index to access the help text database. If the provided ccommand name> is a valid element 
of the system vocabulary, the assistance text is displayed; if not, an error message is presented to the user. The 
help provided usually concentrates on the syntax of the commands, occasionally giving examples, but rarely 
explains how the command fits into the framework of the whole application or discusses related commands 
[G WEI 90]. 

During the system design phase, assumptions are made regarding the amount of computer and topical 
experience the typical user will bring to the session. Assistance texts are written with this “homogeneous 
user” [MOILY 87] model in mind and result in a help structure which has both a single retrieval methodology 
and a preset presentation strategy. Hence, the depth of information provided is invariant and therefore is not 
impacted either by the individual’s experience or ability. 

When the help system is initiated, system-related information such as the hardware system in use, the 
operating system environment and the application being used, is captured. This environmental snapshot 
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provides most of the system-based influence on the help system access process in a typical help system 
structure. The user request, containing the command name for which help is requested, provides the only 
varying component to the help system access equation. The help system builds the help response by 
combining the system-based framework with the command request and displays the pre-programmed 
response to the user. If the user requires amplifying information or information on related actions or 
commands a subsequent help request must be initiated. 

B. INFORMATION USED BY HELP SYSTEMS 

The typical help system structure does not use user or situation-specific information to tailor the help 
system access or presentation strategies. The most basic structure, the command-keyword-request structure, 
is referred to as “static” because the help provided in response to a specific assistance request is pre- 
programmed and is not effected by the dynamics of the user or the task being attempted [BOREN 85]. 
However, additional system- and user-based variables, such as application mode in use, the command history 
of the session and user experience, can be leveraged to provide a dynamic, user-adaptive element to the help 
system structure. Knowing the application mode being applied provides an additional layer of scope defining 
information that enables the help system to more closely focus the retrieval. Focusing the retrieval refers to 
the ability of the system to determine and select for presentation, the help text component that most closely 
fits the user’s help request. For example, if the user is working in a word processing application and wants 
information about formatting, the help system will have to provide all format-related help text However, if 
the application mode in use is known to be “format paragraph”, the assistance need can be more closely 
predicted and the response tailored to provide help information related to the formatting of paragraphs instead 
of merely defaulting to providing information regarding formatting in general. 

Duffy and Langston in [DUFFY 85] put forward one of the more comprehensive discussions regarding 
employing elements of the user environment in help systems. They discuss the “dynamism” of a help system, 
or “the degree to which [the help system] can assess and respond to the user’s needs of the moment” and 
further, they state that this is sometimes referred to as “context-sensitivity”. The system response is 
formulated not only by considering the user’s explicit request but also by factoring in elements related to the 
specific user and to the situation that lead up to the request. By employing user- and situation-specific, or 
context, elements in the help system structure, the help system has a representation of the user environment 
available to it for use in generating help responses that are more appropriate for the user and the situation. 
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C. ISSUES ADDRESSED BY DYNAMIC, CONTEXT- DRIVEN HELP SYSTEMS 



By definition, a dynamic-based system is more complex to build and maintain than a static help system 
structure. Therefore, in order to justify the additional effort, some advantage must be offered by the dynamic 
structure. The following sections address issues involved in considering a dynamic instead of static help 
system structure. 

One of the issues in developing a dynamic-context based help system is determining what types of 
assistance needs can be answered by a dynamic system that can not be served or served as well by the more 
typical static system structure. Assistance needs addresses both the types of questions the user asks (How do 
you....?, How can I use....?, What do I do next?, etc.) as well as the type of help that is needed (general, 
specific, high-level, detailed, etc.). Dynamic structures can assist the user in determining the question that 
needs to be asked. For example, at times the user may be unable to determine which menu selection will 
provide the information needed to accomplish the job being attempted. In this situation, the help system 
mechanism needs to provide a means of prompting or assisting the user, by leveraging the available 
situational information, to lead them to the question they are attempting to ask. 

Dynamic architectures can also support multiple perspectives from which questions may be asked. * 
Each person may think of the task in different ways: one person may think of the task in terms of a particular 
system function, the next may think of it in relation to the other work being done. The help system must be 
able to provide a mechanism for the user to use to map the mental and physical pictures together. The way 
the menu is designed can provide a mechanism to link the user’s mental representation of the problem to the 
help system structure. 

Finally, in addition to responding to the explicit request of the user, dynamic structures also have the 
ability, menu structures that adapt based on the task being attempted, to assist the user in determining the 
next step in a task sequence. Additionally, they provide an indicator to the user regarding their relative 
progress in completing the task sequence. The menu structure must be able to provide a logical representation 
of the how the application is used and should frame the application’s commands available to the user and give 
some indication of their role in the application. 

The second issue relates to capturing and employing the user’s context for providing more specific help 
to the user. In this effort, context is defined to mean those elements, of both the user model and the system 
that form a representation of the working environment. Capturing the context entails not only determining 
how to gather, record and update user and situation elements of the application but also includes determining 
what elements constitute the context of the application and identify the essential elements of the user model. 
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Once the decisions regarding how and what to capture are made, the next step is determining how this 
information can be employed to improve the way the help system access mechanism selects which 
information will be presented to the user. 

Employing the user’s context in focusing the help system entry is then a third issue. Once captured, how 
can the user's context be employed to improve the help system entry mechanism? Static systems typically use 
only the explicit request and process a pre-programmed help text retrieval. By employing user-based 
information such as pre-existing knowledge and/or system-based information such as the specific task being 
attempted, the help text selection process can tailor the response to the user and the user’s work situation. 
Tailoring in this sense means adjusting the amount of information presented relative to the specifics of the 
user and the work being done. 

A final issue addresses formatting the help text to serve users of all levels of experience. The design of 
the help system is driven by the user model. Therefore the more user-related information that can be captured, 
the better we can serve the needs of the user. The typical help system development defines the characteristics 
of the expected/typical user during to the system design phase in terms of the type and amount. A common 
practice is to present the help information using the same structure, regardless of whether the assistance is 
being provided to an experienced user or a novice and with no regard as to what type (general or detailed) of 
information is being requested. A dynamic structure can provide a means of adjusting the information 
presented to more closely fit the needs of the user, providing more in-depth information to the novice user, 
for example. 

This thesis explores these questions via a prototype help system for an interactive software 
environment. TAE+ Help is a help component designed to assist users of the Transportable Applications 
Environment Plus (TAE+). Development of the prototype was accomplished by first identifying the user- and 
system-based elements of TAE+ that form the framework of the application’s context This was followed by 
creating mechanisms to first gather and then employ the context-related variables in the help system access 
and presentation strategies. TAE+ was selected as the target application based on its depth and breadth of the 
command structure. Additionally, although the current application has a built-in help facility to respond to 
“what is this?” user queries, many other types of assistance are not provided. 

Appendix A provides a synopsis on TAE+ V5.1. TAE+ Help is initiated separately from TAE+ but runs 
concurrently in the XWindows environment. When the user requests assistance, TAE+ Help initiates a 
dialogue with the user, collecting situational environmental information and employs these dynamics in the 
help system access process. 
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D. THESIS ORGANIZATION 



Chapter II of this thesis provides a survey of selected online help systems in general, some of the related 
criticisms of current systems and a taxonomy to frame the elements of typical help systems. Chapter III 
describes the methodology employed to develop a dynamic, context-driven help system and the system 
developed to implement these concepts. Finally, Chapter IV presents conclusions and recommendations for 
future research. 
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n. SURVEY OF ONLINE HELP ISSUES 



Online help systems are but one element of the much broader online assistance domain that also 
encompasses online documentation, tutoring, prompting and other such assistance facilities, that element that 
provides a detailed, localized assistance for the domain of immediate interest to the user. This survey is 
concerned only with online help systems; specifically, it defines the system taxonomy that will form the basis 
for describing help systems in this thesis. Since the topic of context is central to the thesis, this chapter 
discusses the role that context and user experience play in developing a help system separately from the 
taxonomy even though one potential dimension of the taxonomy would be the use of context. Lastly, this 
chapter identifies some of the deficiencies of current help systems. 

A. TAXONOMY 

Help systems can be characterized on a number of dimensions: 1) access initiative, the means by which 
the help system is invoked; 2) help mechanism, the interface medium between the user and the help system; 
and 3) help system implementation, the structures used to build the help system. 

1. Access Initiative 

Help assistance can be initiated by the human user, the system or some combination of both. 
Systems are classified in terms of access initiative by categorizing them based on the degree to which the 
system is user- versus system-initiated. The vast majority of systems are user-initiated, that is, help text is 
provided after a help request is explicitly entered by the user - for example “help <command name>”. Systems 
that supports both user- and system-initiated help are call mixed-initiative systems. An example of a mixed- 
initiative system, is the WEST system [BURTO 82], which monitors the user’s actions and compares the 
decisions the student makes to the expert module. The help structure provides recommendations for more 
advantageous moves or actions, as warranted by the user’s actions, as well as provides textual help in 
response to an explicit user request. The final type of help initiation would be a help component that initiates 
all help assistance. There is no facility by which the user can request assistance; instead the system controls 
the entire operation and initiates further activity as needed. 
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2. User-Initiated Help Mechanism 

The help mechanism is the interface mechanism by which the user relates to the help system. 
Possible mechanisms include command-keyword-request, menu-selection, active screen buttons, natural- 
language request and spoken-phrase request Command-keyword-requests are the most common form of help 
mechanism ([GWEI 90] and [HOUGH 90]) and require the user to enter “help” followed by the command 
they are requesting assistance for. Novice users have the greatest difficulty effectively using this type of help 
system due to the implicit requirement to have pre-existing knowledge about the system and its commands 
[GWEI 90]. Menu selection provides the user with a list of the available help topics from which a choice can 
be made. This mechanism provides more assistance for the novice by providing a visible list of the available 
commands but still doesn’t assist in the issue of relating the commands to the task at hand and also is often a 
source of frustration to the experienced user forced through a time-intense access process. A mechanism that 
is becoming more common is designing user-interface screens with areas on the screen that function as 
buttons. When these buttons are selected (usually by pointing and clicking with a mouse), help texts are 
shown explaining the item and its purpose relative to the application. This mechanism can be effective for the 
user “exploring” the application but is less helpful when the user has a specific task in mind and is searching 
for the appropriate command to accomplish it Technology in the intelligent and expert system arenas is 
making advances on providing two additional mechanisms: natural-language requests and spoken-phrase 
requests. Natural-language-requests allow the user to enter a request in the form of a sentence that the system 
then analyzes [GWEI 90]. Spoken-phrases incorporate speech recognition, taking an orally-spoken request 
and parsing it for keywords. To date, spoken-phrases have been successfully applied only in limited domains 
[BOREN 85]. At a minimum, systems usually include a command- keyword- request help component and 
frequently have multiple help mechanisms, for example, command-key word- request and menu-selection 
mechanisms. 

3. Help System Architecture 

Another element of help system development that varies significantly is the amount and type of 
structural mechanisms that are used in building the help system. Two variants, the utility of which is still 
being addressed in current literature, are the ideal number of levels of assistance to provide to the user [GWEI 
90], [CHERR 89] and [FARRA 92], and whether or not the help system should be part of the application or 
part of the system as a whole [BOREN 85]. 
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a . S ingle - versus Multiple -Le veling 



A help system structure may be designed to provide a single level or multiple levels of 
assistance. An example of a single level system is the UNIX “man” (manual) command that provides a copy 
of the online manual text in response to the user query. The help text may include a recommendation to 
reference related commands but any subsequent help assistance must be initiated by the user with an 
additional “man” command [GWEI 90]. Other systems employ a hierarchial menu arrangement of topics and 
subtopics [CHERR 89] to facilitate navigation through an electronically linked set of help texts. Links may 
be designed to enable the user to access more detailed texts of the help topic or to access related topic help 
information. A single level of help provides a simple, easy to understand help structure. Farrand and Wolfe 
in [FARRA 92] argue that the objective should be to provide simpler and fewer types of help. However, 
single-level structures sacrifice the power of the multi-level structures. Use of just one additional level 
provides a mechanism for grouping topics under higher-level titles and reduces the cognitive complexity of 
the access interface. 

b. Integrated and Integral Help System Implementation 

Many systems provide several online help system access mechanisms, for example, 
command-keyword request and menu selection. The level of integration refers to the degree of independence 
the different help mechanisms operarate under. If all system help components access the same database and 
enable the user to query on any topic independently of the task at hand, it is a fully-integrated help system. 
[BOREN 85] More commonly, each application has its own help system and a help text database that is 
accessed only when the user is working within the application. 

“An integral help system is one in which the help is provided by the same program that 
executes the command[BOREN 85]. In other words, the help system is invoked from within the application 
and is actually a part of the application as opposed to being part of the system that runs the application. The 
advantages of non-integral help systems include providing the user with a consistent interface that is 
accessible from all applications and often a more comprehensive help mechanism vice the application- 
specific help. 
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B. ACCESSING THE HELP SYSTEM 



1. Types of User Queries 

Seilen and Nicol conducted a number of studies to determine what types of questions users asked. 
They were able to group the queries into five broad classes of questions as depicted in Figure 1 . These classes 
will be used in subsequent discussions throughout this thesis. 



1. Goal-oriented 

2. Descriptive 

3. Procedural 

4. Interpretive 

5. Navigational 



What kinds of things can I do with this program? 

What is this? What does this do? 

How do I do this? How do I accomplish a specific operation? 
Why did that happen? What does this mean? 

Where am I? 



Figure 1. Classes of Help Questions [SELLE 90] 



In general, goal-oriented and descriptive queries are used by novice users in the process of 
familiarizing themselves with the application and system. Visibility of the existence of the help component 
and ease of access are more important aspects than efficiency, as these help components are referenced 
relatively infrequently by any one user, but may be critically important when they are. Procedural queries are 
the most common type of queries [SELLE 90] and are used more frequently in general and by all categories 
of users. Therefore, access mechanism efficiency and ease-of-use are important elements in providing 
appropriate help information in a format useful to all users. Interpretive and navigational questions relate to 
why and where elements in help systems. These help elements are still relatively novel components in today's 
help system arena. 

Two observations related to online help systems emerge: First, “the kind of information delivered 
should be different depending on the (type of) question asked" (or implied) [SELLE 90]. A user asking a 
procedural question is likely looking for specific, pointed information, while a request for goal-oriented 
information indicates more expansive help may be appropriate. Second, “the way in which information is 
accessed and presented should depend on the question asked" [SELLE 90], A request initiated by a pointing 
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action is likely a descriptive query. Contrast this with a command-keyword request. The latter inquiry is likely 
more proceduraUy oriented, the former more of a descriptive query. In each situation the type of questions 
and the manner in which the users ask them are factors that can be employed in the help system design 

process. 

2. Task-Based versus Function-Based Menu Orientation 

Jackson, Cherry and Fryer in [CHERR 89] describe a task-based menu structure that maps the 
order of menu topic titles to the sequence of typical activities that a user must perform to accomplish a major 
goal. The grouping of titles gives the user a high level view of the whole task and of the sequence of events 
required to accomplish the work. The objective of this type of menu structure is to assist new users in 
becoming productive quickly. Additionally, the structure provides an efficient access mechanism for 
experienced users with a specific request. A function-based menu provides an alphabetical listing of all of the 
available application commands. Novice users have a more difficulty using this type of help system as it 
provides no assistance to the novice user attempting to determine which commands are needed to accomplish 
the task being attempted [CHERR 89]. 

C. THE ROLE OF CONTEXT 

Duffy and Langston [DUFFY 85] define the “dynamism” of a help system to be “the degree to which 
[the help system] can assess and respond to the user’s needs of the moment” and further, they state that this 
is sometimes referred to as “context-sensitivity”. Although the term “context-sensitive” has been used for 
many years in discussions related to help systems, a universally-agreed-upon meaning has not yet emerged. 

Relies and Sondheimer [RELLE 81] describe characteristics of effective online help systems to include 
“context sensitivity - the ability to provide assistance relevant to the user's current situation”. When referring 
to context, they speak of environmental information related to the user, the application and the tasks being 
performed. Houghton [HOUGH 90] espouses that the employment of context would be one way to make the 
help system less disruptive and thus assist the user in maintaining the mental context of the work environment 
while accessing the help environment Maass [MAASS 83] declares that systems in general should be able to 
maintain a “self-image” of their current state and provide explanations to the user about current alternatives 
and expected formats; this to be accomplished by providing a context-sensitive help system. Sellen and Nicol 
[SELLE 90] postulate that the more context-sensitive help can be made, the less obtrusive it will be for users. 
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Burton and Brown in [BURTO 82] describe a expert, computer-based coaching system, “How the West 
was Won” that gathers the context of the player’s game by monitoring the moves the player makes. These 
are compared to expert module where an evaluation is done to assess the quality of the move. 

All systems can be characterized based on the use of context by using a continuum ranging from static 
help systems, typified by the conventional command-keyword-request system, to dynamic systems like 
intelligent or knowledge-based systems. The command-keyword-request system is referred to as “static” 
because the help provided in response to a specific assistance request is not altered by user characteristics or 
actions. In knowledge-based systems some combination of user experience, the most recently entered 
command and/or command history is employed by the system to determine what type or amount of help is 
needed and therefore is characterized as dynamic. 

D. USER EXPERIENCE 

An additional element is often discounted when discussing help systems: user experience, the amount 
of both computer and topical experience the user brings to bear in system interactions. Relatively few of the 
authors substantially address the variation in the type and amount of assistance that is required by an 
experience-diverse target audience, often stating only that the help system must serve all types of users. The 
expected proficiency of the user should weigh heavily in design decisions, effecting everything from the 
amount, type and format of the provided information to the topic organization and access mechanism. 
Unquestionably, the “novice-novice”, a user inexperienced in both computer use and the specific application 
requires more in-depth assistance than the “experienced-novice”, a user experienced with computers but not 
the application. These needs will also vary significantly from those of the “experienced-experienced” user in 
search of very specific assistance, for example, command syntax. 

E. SHORTFALLS OF CURRENT HELP SYSTEMS 

Several authors catalogue/detail deficiencies of current help systems or propose critical elements to 
consider in designing new systems. Shortfalls that are often cited of help systems include: 

- users are required to sift through large verbose help texts for relevant information [BOREN 85] 

- users must have knowledge of the available commands, their relevance to the task at hand and the 
command syntax [GWEI 90], 

- users are required to physically as well as mentally switch contexts from the work context to the help 
system context [RIDGW 87]. 
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- users are provided with a 'canned* help text response, that is, the type and amount of information is not 
influenced by the state of the user's environment or skill [MOELY 87] and often is too general to be of any 
assistance. 

- users aren’t able to determine which commands and actions are needed to accomplish the task being 
attempted [CHERR 89]. 

The single message arising from the plethora of help design and implementation articles is that there 
still is little consensus in the field as to what the characteristics of a good help system are. In fact, Borenstein 
[BOREN 85] concluded “...help systems in general use are so uniformly unappealing that designers who do 
make an effort to construct worthwhile help systems tend to assume that they are starting with a clean slate, 
working on a problem that has never been seriously confronted before....” 

Dynamic, context-driven help system improvements proposed in the previous chapter have the potential 
for relieving many of these deficiencies. The improved access mechanism will result in a more focused 
retrieval and a response that is more relevant to the situation. Additionally, user-specific information is used 
throughout the access and presentation processes to tailor the response to the experience level of the user. 
Improved menu structures will provide a means of presenting a structured command list showing the user not 
only the commands available for use but also will provide a framing mechanism indicating the role the 
commands play in the application. By employing user- and situation-specific, or context, elements in the help 
system structure, the help system has a representation of the user environment available to it for use in 
generating help responses that are more appropriate for the user and the situation. 

F. CONCLUSION 

This chapter has presented the user with a taxonomy, or framework, for discussing help systems and has 
discussed the role of user experience and context in recent help system literature. Additionally, deficiencies 
cited by displeased users are presented attempting to project the magnitude of the problem. The next chapter 
discusses the steps necessary to develop a dynamic, context-driven help system and offers a prototype to 
demonstrate the advantages the dynamic structure offers over more typical help system structures. 
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m. DYNAMIC, CONTEXT-DRIVEN HELP SYSTEMS 



The initial step in developing a dynamic, context-driven help system is to identify the elements of the 
application environment that form the framework of the application’s context The help system must first 
gather and track these context elements and then incorporate them into the help system access decision 
mechanisms to provide an improved help system structure. TAE+ Help has been developed to demonstrate 
the viability, feasibility and utility of a dynamic-context driven help system. System development excerpts 
will be referenced periodically throughout this thesis. Appendix A provides a synopsis of the Transportable 
Applications Environment Plus (TAE+) software development environment application. 

A. IDENTIFYING CONTEXT 

Context, as defined for use in this thesis, consists of two components, system-based context and user- 
based context System-based context elements are identified by actual examination and recording of the 
system in question; user-based context identification is accomplished by projecting information regarding a' 
typical/hypothetical user of the application. The following sections provide the details of this process. 

1. Identifying System-Based Context 

Two steps are required to identify and record the elements of a system that define the system-based 
context. The first step entails developing state-transition diagrams (STDs) to model the system behavior of 
the application that the help system is being developed for. STDs depict the path(s) through which each state 
can be reached, the possible transitions out of the state, the catalyst(s) that cause each transition and the 
subsequent state that results from the transition. These STDs are then employed in the second development 
step to isolate/identify system functions and actions supported within each state. Appendix B provides STDs 
generated to model applicable portions of TAE+. TAE+ Help STDs associate a state with each TAE+ 
window/subwindow. 

Each STD state is examined individually to identify and record the questions the user may ask/ 
have while working in the state. Seilen and Nicol in [SELLE 90] define five types, or classes, of help-related 
questions users typically ask: goal-oriented, descriptive, procedural, interpretive and navigational. A table is 
constructed that cross references, by question class, the questions discovered in each state and the STD state 
they apply to. In addition to the organizational benefit, this question- state table construct provides a check- 
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and-balance mechanism to ensure comprehensive coverage of the state assessment process. The developer 
first lists the questions that arise after the initial review of the state and groups them according to the five- 
class structure. Then the content of the resulting question-state table is reviewed from the perspective of each 
class of question, to ascertain all probable questions have been included. The content of the question-state 
table then becomes the foundation document for development of a three-tiered menu system that will be used 
to gather the user’s working context Appendix C provides the question-state table containing the questions 
that arise at each TAE+ state. TAE+ V5.1 supports the descriptive questions within the current application 
and thus they have not been included in this effort 

A second table is constructed for recording visible objects, or observables, such as subwindow(s) 
titles, icons, operating mode setting, etc., within the state that are state-specific. The observables-table 
structure also includes developer notes regarding supplementary questions that may be asked of the user to 
more closely pinpoint the context elements where there remains a lot of context ambiguity. Appendix D 
provides a table of the observable context clues associated with each TAE+ state. 

These two table structures represent two of the system-based context elements that must be 
captured and employed in the developmental help system. The final system-based component is the 
application mode in use. Typically, the application mode categories offer a high-level, system-partitioning 
mechanism that can be used to quickly reduce the search list of potential topics that must be considered during 
the help system access process. If the application mode being applied is known, entire sections of the system 
can be dismissed during the initial topic honing effort, leaving a smaller, more manageable quantity to address 
in subsequent searches. The more closely the target topic can be pinpointed during the access process, the 
more request-applicable the information that can be provided to the user. The next component that is 
addressed is identification of the user-based context elements. 

2. Identifying User-Based Context 

User-based context elements, when considered together, form the user model that will be assumed 
throughout the development The model should profile the typical user of the application; in the case of a help 
system, this still infers a very broad range of capabilities/knowledge that must be provided for. Elements to 
consider include user experience and help-system-command execution history. 

a. User Experience 

The amount of previous experience the user brings to the session contributes significantly to 
decisions regarding how much help information is provided to the user in reply to a request for system help 
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and the manner in which it is presented For example, novice users need more intuitive menu selections to 
choose from and in the case of requests for very specific/narrow scope information, it may be advisable to 
provided additional assistance in the form of more general topic help. Also, previous experience may not 
necessarily be directly related to the target application in order to be considered significant. An additional 
type of experience available for use in the access decision process arises if the topic in question in some way 
relates to another topic that the user may be familiar with. In this instance, the provided help text can be 
presented in terminology relating the known topic to the requested topic, assisting the user in using pre- 
existing knowledge to interpret and understand the new situation. 

b . Menu Selection History 

Topic selection and the history of topics selected by the user are also important elements in 
the help system access process. The user’s topic selection itself indicates the explicit user request and may 
also imply the application development stage that the user is currently working on. However, the history of 
topics selected implies additional information about what assistance the user may need. For example, if the 
user is a novice and has not requested or been shown general information about a concept, responding directly 
to a very specific topic request may not be adequate. It may be advisable to preface/supplement the specific 
topic response with a broader topic discussion segment to clarify its full role in the application. 

B. GATHERING CONTEXT 

Once the meaningful elements of the context are identified, they must be collected and tracked for use 
in the help system access decision process. System-based context elements are gathered by recording the 
application mmode and menu/submenu selections made by the user. User-based elements are gathered by 
monitoring the skill level and past experience of the user. 

1. Gathering System-Based Context 

A three-tiered menu system is used to create a multi-prospective view of the target application 
system for the user. By monitoring the menu topic selections made by the user a context model can be 
constructed and used as the basis for determining what topic the user is interested in. 

a. Subwindow Menu 

The highest-level menu structure, the Subwindow Menu , is developed from, and ordered by, 
the hierarchy of the application’s sub window titles. The user selects the menu title that corresponds with the 
title of the application subwindow being worked in. Embedded submenus prompt the user for more 



15 



information regarding their help request by projecting lists of probable topics and thereby provide a 
mechanism for capturing more of the user’s working context. The Subwindow Menu provides the user with a 
very efficient help access mechanism, directly mapping the question-related application window to the help 
structure and quickly focusing the help topic lists to the probable topic area. Supplemental submenus, 
embedded within the subwindow structure, enable remaining topic ambiguity to be further reduced. 

b . Task-Oriented Menu 

The second tier, the Task-oriented Menu , is ordered based on the sequence of tasks 
accomplished during a typical development. The user selects the menu title that corresponds with the task 
currently being worked on or for which information is being requested. Supplementary questions may be 
asked to determine if the user has any other direct/indirect experience that may be leveraged to best answer 
the current request The user is able to relate the task being accomplished directly to the menu structure, 
providing an indicator of what the user’s working context is now, what the next context is likely to be and 
allows suppositions to be made regarding what the user has knowledge of. For example, in TAE+ Help, if the 
user is currently working on specifying an item, it can be assumed that the tasks related to resource file 
manipulation and panel specification have already been accomplished by the user and it is probable that help 
requests in the near term will relate to the details of building and placing items. 

c. Function-Oriented Menu 

The final tier, the Function-oriented Menu consists of an alphabetical listing of the projected 
system functions that have been derived from the question-state table contents. The user selects the menu title 
that best represents the topic for which help is being requested. The function-oriented listing is the finest- 
grained topic listing, providing the building blocks to represent all the atomic/fundamental context elements 
of the application. Whereas the subwindow and task-oriented structures assist in the capture of the physical 
working context of the application, the function-oriented structure provides a capability for capturing the 
user’s mental context of the problem in situations where the request is unrelated to the current physical 
context. 

The three-tiered menu system provides the user with a help system configured in multiple fashions, 
enabling the user to map his mental picture to the most appropriate help view, and thereby reducing the user’s 
cognitive load when moving between the work and help environments. The subwindow and task originated 
requests use their respective structures to support the gathering of the context-based elements of the situation 
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and pinpoint the primary topic title. System control then passes to the function-oriented structure to present 
the requested help text Access to the menu structures is provided to the user through left-, middle- and right- 
button mouse clicks to reach the Subwindow, Task-oriented and Function-oriented Menus respectively. 

d . Application Mode 

The application mode setting information is gathered during the initial system entry process 
and again whenever the user’s topic selection indicates the application utilization has moved into a different 
mode. In TAE+ Help, the mode the user starts working in is the Move/Resize/Edit mode. Menu lists are 
ordered to first present the topics expected to be encountered by the user working in that mode. If the user 
subsequently requests assistance on defining Panel connections this is an indicator that the application mode 
has changed or should be changed to Define Connections. If, in fact, the development has progressed to the 
point of defining connections between objects and panels, a further supposition can be drawn that the topic 
lists should be reordered to fust present titles related to defining connections and other tasks that fall after that 
point in a typical development effort. 

2. Gathering User-Based Context 

User-based context element information is gathered initially upon entry into the system and then 
is updated dynamically throughout the session. Contributing elements include user experience and command 
history. 

a. User Experience 

The initial experience level setting is based on responses to an experience assessment 
conducted when the user first enters the help system. Questions designed to break users out into 
distinguishable levels of experience are presented and the responses are used to derive the assigned 
experience level. In the case of TAE+ Help, the user is queried as to the extent of their experience in the use 
of the more complicated TAE+ capabilities. Their replies are then used to classify them as novice, 
experienced or knowledgeable users. Subsequent application use adjusts this proficiency variable 
dynamically to more closely map the demonstrated user skill to both the amount and type of provided 
information. For example, if the user replies indicate they have experience with several of the more advanced 
development procedures, the user is classified as Knowledgeable. However, if a user classified as 
Knowledgeable selects very fundamental menu topics, the user will be re-classified to downgrade the 
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assigned experience level to Experienced Conversely, a user classified as Novice will automatically be 
upgraded to Experienced after accessing the post-TAE+ Item topics. 

b. Menu Selection History 

The command selection history together with the experience level of the user are the 
fundamental factors in the help system access decision process. The command history is accumulated by 
flagging each help script element that is viewed by the user. In TAE+ Help, a topic is flagged as shown after 
being viewed by the user. The experience level of the user, along with the list of shown topics, contribute to 
the decisions regarding what the user sees in response to the current request and when the experience level of 
the user is modified/adjusted. If the user is a novice user and is requesting assistance on a very specific topic, 
a check is done to see whether the user has viewed the more general topic script. If not, the general 
information is presented and is followed by the specific topic requested by the user. Further details of this 
process are provided in the following sections. 

C. USING CONTEXT 

The gathered context elements are used and updated throughout the application session. The 
organization of the menus and user experience, direct or indirect, are the primary context driven components 
that evolve as system utilization progresses. The following sections provide the details of the how context is 
employed in the developmental help system. 

Appendix E provides a program listing of TAE+ Help. It has been developed using a special-purpose 
grammar, interpreter and parser created by D. Masked [MASKE 92]. Page 2 of Appendix E provides an 
example describing the structure of the state-based grammar. Appendix F provides this grammar in Backus- 
Naur Form (BNF). In general, the format is as follows: in the program listing each code segment defines the 
state being specified, the action(s) that result upon occurrence of the state and the catalysts that cause a 
transition and associated actions that result from invocation of the catalyst. 

1. Using System-Based Context 
cl Menu Access Mechanisms 

The application mode being employed by the user is used as a partitioning mechanism to 
tailor menu access points, providing the menu page to the user that contains the topic titles associated with 
the application mode in use. For example, if the current WorkBench Mode is Define Connections, it is 
probable that the user is searching for Panel-related help. Therefore, the menu page that should be provided 
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first should be the page that contains the Panel-related topic titles. Conversely, if the current WorkBench 
Mode is Set Item Default, it is probable that the user is searching for Item-related help. The page that contain 
the Item titles should be presented first. 

b . Menu Transition Mechanisms 

The underlying premise of the menu/submenu transition is that presenting topics on the new 
menu page that are most-like the topics on the page that was left, helps the user maintain the mental context 
of problem request and directly presents “most-probable” topics for further selection. In TAE+ Help this 
occurs in both main menus (Subwindow, Task-oriented and Function-oriented Menus) and submenus (within 
the Subwindow Menu structure) to main menus. 

Code excerpts from Appendix E are provided in Figure 1 below to demonstrate the menu-to- 
menu transition process. (An explanation of the grammar is detailed on page 2 of Appendix E.) The following 
code segments are from states st_l_3_300 and st_l_2_150. While in state st_l_3_300, page 2 of the 
function-oriented menu structure, if the user clicks the left mouse button (click-left), control transfers to state 
st_l_2_150, the subwindow page containing topic titles most-similar-to those found on the st_l_3_300 page. 
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